<html>
<head><meta charset="utf-8"><title>session locking · t-compiler/wg-incr-comp · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/index.html">t-compiler/wg-incr-comp</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html">session locking</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="240362833"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240362833" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240362833">(May 26 2021 at 17:45)</a>:</h4>
<p>I have a naive question.  Is locking of the session directory necessary when running under Cargo?  From my understanding, a single <code>rustc</code> invocation only uses a single session directory for the crate being built. That directory name includes the crate disambiguator. Since cargo always gives unique <code>-C metadata</code>, there should never be a circumstance where there are concurrent rustc processes pointing at the same incremental directory.  Does that sound about right?</p>



<a name="240371075"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240371075" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240371075">(May 26 2021 at 18:42)</a>:</h4>
<p>I don't think it should be necessary for successful builds, but it can't hurt.</p>



<a name="240371766"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240371766" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240371766">(May 26 2021 at 18:47)</a>:</h4>
<p>It causes problems for filesystems that don't support locking.</p>
<p>There's more context at <a href="https://github.com/rust-lang/rust/pull/85698">https://github.com/rust-lang/rust/pull/85698</a>.  I fixed the ICE that happens, but I'm trying to decide if I should go further and change the behavior when it can't lock.  Cargo just silently ignores it.  I'm thinking of changing rustc to do the same.  But then, I was thinking, why does rustc bother locking at all?  </p>
<p>WDYT about just ignoring unsupported file locks?</p>



<a name="240386564"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240386564" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240386564">(May 26 2021 at 20:29)</a>:</h4>
<p>When cargo doesn't lock at worst two compilations at the same time could cause an SVH mismatch causing rustc to error out due to not finding an indirect dependency with the right SVH. When rustc doesn't lock the incremental session dir, the depgraph, workproduct index and the cached object files could be read at different times and thus go out of sync with each other. In the best case this will result in a linker error or an ICE. In the worst case this will cause a silent miscompilation.</p>



<a name="240387099"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240387099" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240387099">(May 26 2021 at 20:32)</a>:</h4>
<p>Erroring on out of sync depgraph and workproduct index would be possible if both embed the SVH, but the object files don't have any kind of unique identifier embedded and using a hash of the object files to detecr mismatches would be slow due to the hashing and it would be necessary to copy the object files to a temp dir, then check the hash and finally link the copy to prevent a TOCTOU race.</p>



<a name="240443592"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240443592" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> mw <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240443592">(May 27 2021 at 10:07)</a>:</h4>
<p>Some thoughts:</p>
<ul>
<li>Even if we could assume that <code>rustc</code> runs under cargo I'd still feel a lot better to have precautions in place that (try to) make sure that no two <code>rustc</code> process use the same cache directory. As <span class="user-mention" data-user-id="133247">@bjorn3</span> points out anything can happen in that case.</li>
<li>I think file locks are also used for making sure that directories don't get garbage collected while another process is still accessing them. At some point in the history of incr. comp. <code>rustc</code> processes would read data from the cache directories of upstream crates. I don't know if that is still true but if it is, there can be any number of processes reading a cache directory concurrently and locks are the way to make sure garbage collection knows about that.</li>
<li>The whole synchronization setup is woefully underdocumented <code>:/</code> I suspect that it isn't optimal either performance-wise. Unfortunately, since anything interacting with filesystems is rather brittle and platform-dependent, it would be quite a bit of work to change things here. Might be an interesting project for <span class="user-group-mention" data-user-group-id="3282">@wg-incr-comp</span> at some point.</li>
</ul>



<a name="240444505"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240444505" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> mw <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240444505">(May 27 2021 at 10:16)</a>:</h4>
<p>Having a good error message instead of a panic is a great improvement! Thanks for implementing that, <span class="user-mention" data-user-id="120518">@Eric Huss</span>!</p>



<a name="240445514"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240445514" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> mw <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240445514">(May 27 2021 at 10:26)</a>:</h4>
<p>Out of curiosity: how does cargo synchronize between concurrent processes trying to build the same directory? From the message on the commandline it looks like it's using file locks too:</p>
<div class="codehilite"><pre><span></span><code>$ cargo build
Blocking waiting for file lock on build directory
</code></pre></div>



<a name="240446140"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240446140" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240446140">(May 27 2021 at 10:32)</a>:</h4>
<p>There is a file <code>.cargo-lock</code> inside <code>target/{debug,release}</code>.</p>



<a name="240488047"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240488047" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240488047">(May 27 2021 at 15:46)</a>:</h4>
<p>The locking code is <a href="https://github.com/rust-lang/cargo/blob/e931e4796b61de593aa1097649445e535c9c7ee0/src/cargo/util/flock.rs#L262-L343">here</a>.  It is slightly more complicated than the rustc version, in that it checks for NFS mounts, and will block to wait for the lock instead of returning immediately.</p>
<p>Thanks for the responses!  I think keeping it as-is for now is probably good.  Hopefully the note added in the PR will guide people on how to resolve the issue.</p>



<a name="240488759"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/241847-t-compiler/wg-incr-comp/topic/session%20locking/near/240488759" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Eric Huss <a href="https://rust-lang.github.io/zulip_archive/stream/241847-t-compiler/wg-incr-comp/topic/session.20locking.html#240488759">(May 27 2021 at 15:50)</a>:</h4>
<p>I think not coincidentally, both implementations were written by Alex.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>